Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9704/000005_owner-urn-ietf _Wed Apr 2 16:05:15 1997.msg

Internet Message Format | 1997-04-30 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id QAA28374
    for urn-ietf-out; Wed, 2 Apr 1997 16:05:15 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id QAA28368
    for <[e-mail]>; Wed, 2 Apr 1997 16:05:12 -0500 (EST)
Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21160  (mail destined for [e-mail]); Wed, 2 Apr 97 16:05:01 -0500
Message-Id: <[e-mail]>
Received: by privateer.windrose.omaha.ne.us; Wed Apr  2 15:05 CST 1997
From: "Ryan Moats" <[e-mail]>
To: "Daniel LaLiberte" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Date: Wed, 02 Apr 97 15:07:53
Priority: Normal
X-Mailer: PMMail 1.91 For OS/2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [e-mail]
Precedence: bulk
Reply-To: "Ryan Moats" <[e-mail]>
Errors-To: [e-mail]

On Wed, 2 Apr 1997 13:57:00 -0600 (CST), Daniel LaLiberte wrote:

>Ryan Moats writes:
> > Reasons that come to my mind for having "urn:" (I don't claim that anybody
> > else needs to agree with these...):
>
>So that's how it happened.  The previous time I had checked the
>syntax, the "urn:" was still optional, as I recall.  I don't recall
>any explicit statement to the mailing list that "we are now going to
>make 'urn:' required - any comments?".  Oh well, you wanted a brand
>name to protect, so you got it.

I don't claim this are the accepted reasons by the whole group
(or why "urn:" became required in the first place), these are just what
came to my mind while thinking about Dan Connely's questions over
the weekend (since "it's a closed topic" doesn't seem to work).
In fact, I take umbrage at the implication of the first sentence, because
that is NOT "how it happened".

 As to the explicit statement about the "urn:" becoming required,
there was one and it is in the archives.   I sent mail to the URN list
Mon, 16 Dec 1996 (Message-Id [e-mail])
that was a pre-release of the syntax-02 draft.  This message included
a list of changes in the syntax draft.  Change #2 (I'm quoting now...)

    "2. The tag "urn:" is now required.  There were several folks at San
    Jose that said that the absence of this tag would break things, while there
    was no one that said the presence of this tag would break things. If
    someone has a situation where the presence would BREAK things
    (not just be inconvient) let the mailing list know!"

> > 1. URNs are NOT URLs.
>
>Argument by affirmation, as Dan Connolly says.  Doesn't help.

This position has been stated before on the mailing list, and (my humble
opinion, not fact) I think the majority of the WG agrees with this...

> > 3. Currently (based on my interpretation of URL schemes, your mileage may
> > vary), each and every URL scheme has a "resolution" "protocol" tied to it.
>
>Not true.  There is an associated protocol for most URL schemes, but
>it is not necessarily used.  *If* you use the protocol, then you have
>protocol-specific info in the URL.  But if you do not use the
>protocol, then you still can use the same info.
>
>E.g. web clients do, in fact, use things besides HTTP in resolving
>http URLs.  They are not prohibited from doing so.  It doesn't help
>to deny this.

I assume that you are stating that they do something other
than do a DNS lookup of the name and connect with HTTP.
If so, I have a hard time reconciling this with RFC 1738, which
states that "The <tag> URL scheme is used to designate Internet
resources accessible using the <tag> protocol", where
<tag> is FTP, Gopher, HTTP.  The statement is slightly different
for other protocols, the concept of tying protocol to scheme is there.
If a browser doesn't use the <tag> protocol to retrieve a <tag> URL scheme
resource then why have the <tag> scheme at all?
As an extension, if a browser isn't following this, then why can't it
be claimed that that browser is not supporting the proposed standard
and is therefore a BAD thing?

> > The URN working group is proposing that initially there be a set of
> > "resolution" "protocol(s)" for URNs tending toward a single
> > resolution protocol.  All of these are independent of the URN NID.
>
>Just to clarify, what you are calling "resolution protocols" are being
>called RDS protocols by other people, if I read you correctly.

Yes, and I apologize for my inexact wording.

> > 3a. (#3 has the result that URN-aware browsers do not have to be
> > modified if a new NID is defined as compared to what is required for
> > supporting a new URL scheme.
>
>Not true.  Browsers could resolve all current URL schemes as well as
>any new schemes using an RDS mechanism.

If you build an RDS mechanism into the browser, then I claim it to be
a URN-aware browser, rather than just a URL-aware browser.  I should
have been more specific here.

[The rest of the mail has been deleted because I read Dan's statements
to be agreeing with mine, but I may be wrong]

Ryan